In some conventional client/server architectures which are equipped for operation in the object oriented paradigm, a client sends a request to a server, and the server streams well-defined objects (i.e., objects with no direct ties to other objects) back to the client in response to the request. Once the client receives these well-defined objects, the client is equipped to operate in accordance with these objects.
Unfortunately, the possibility exists that a user could attempt to operate an older versioned client with a more recently developed server. That is, (i) the user may upgrade the server so that the server now is configured to provide both the original well-defined objects as well as new well-defined objects, but (ii) the user may not concurrently upgrade the client. Rather, the user may inadvertently forget to upgrade the client, the user may purposefully avoid upgrading the client with a desire to continue to use the client in a legacy manner, etc.
In such a situation, the older versioned client would send a request to the more recently developed server. The more recently developed server would respond to the request by providing a stream of well-defined objects which includes both the original well-defined objects as well as the new well-defined objects. However, the client would not be able to construct the new well-defined objects and would thus fail to process the stream of well-defined objects properly.
To avoid such a failure, the user may employ a variety of approaches. One approach (hereinafter referred to as the “common version approach”) involves the user adding new well-defined objects to the client/server architecture only if the user is able to contemporaneously upgrade both the client and the server in order to maintain the client and the server at a common version. For example, suppose that the client is one year old and needs to have functionality with a newer server. Under this approach, the user avoids (i.e., defers) upgrading the server so that the server only streams well-defined objects that are one year old (or older). Such upgrade deferment of the server (i.e., the server and the client continuously reside at a common version) prevents the server from streaming a newer well-defined object to the client that would otherwise cause the client to fail.
Another approach (hereinafter referred to as the “embedded approach” involves the user adding new well-defined objects to the server, but configuring the server to stream the new well-defined objects to clients piece by piece as atomic items embedded in an older well-defined object. If a client knows of the new well-defined objects, that client recomposes the well-defined objects by knowing the appropriate order of the streamed atomic items. That is, this “newer” client recognizes the pieces when the pieces get streamed. On the other hand, a client that does not know of the new objects ignores the pieces. That is, this “older” client simply “drops the pieces on the floor” so to speak. Accordingly, the older client will not attempt to construct an unrecognized object that would otherwise cause the older client to fail.
Yet another approach (hereinafter referred to as the “no-longer supported approach”) involves the server being upgraded with new well-defined objects indiscriminately. During the server upgrade, the server receives a new well-defined subsystem representation (e.g., a new version number). If an older client targets the server but does not recognize the new subsystem representation, the older client receives data telling the older client that client's subsystem is no longer supported. That is, the older client is not provided with a stream of well-defined objects thus preventing the older client from attempting to construct an unrecognized object and failing. This is often the route taken by manufacturers with a new hardware platform where the customer is required to upgrade the client software simultaneously with the server software in order to for the client to remain supported.